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A COMMUNICATION SYSTEM 



Field of invention 



-< 



5 The present invention relates to a communication system, in 
particular to the provision a presence service in a 
communication system. jJj 

Background to the Invention ^ 

10 ^ 

A diverse range of communication systems are in use today ^ 

enabling communication between two or more entities, such as gj 

user equipment and/or other nodes associated with the system. fj^ 

o 
o 

15 Communication systems proving wireless communication for user ^ 
terminals or other nodes are known. An example of a wireless 
system is a public land mobile network (PLMN) . A PLMN is 
typically a cellular network wherein a base transceiver 
. station (BTS) or similar access entity serves user equipment 
20 (UE) such as mobile stations (MS) via a wireless interface. 
The operation of the apparatus required for the communication 
is usually controlled by one or more control entities, which 
themselves may be interconnected. One or more gateway nodes 
provide for connecting the PLMN to other networks. Examples of 
25 other such networks are another cellular network, a public 
switched telephone network (PSTN) and packet switched data 
networks such as an IP (Internet Protocol) based network. The 
communication between the user equipment and the other 
elements of the communication system . are based .on an 
30 appropriate communications protocol, which defines the "rules" 
under which communication is handled in the system. 
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in the current third generation (3G) wireless system, there 
are defined various servers for the handling of different 
communication services for mobile users. These include servers, 
that provide call state control functions, known as CSCFs. 
5 Control functions may also be provided by entities such as a 
home subscriber server .(HSS) and applications by various 
application servers. The HSS is typically for permanently- 
storing the user's profile and used during authentication, for 
example, in the Release 5 architecture for 3G, as specified by 
10 the 3 rd Generation Partnership Project (3GPP) , these entities 
can be found located in the IP Multimedia Subsystem (IMS) . 

The IMS network may sit at the hub of the 3G architecture, 
supporting an IP based network that handles both traditional 
15 voice telephony and multimedia services. The 3GPP has chosen 
Session Initiation Protocol (SIP) as a core session signalling 
protocol for 3G networks. SIP has been developed by. the 
internet Engineering task Force (IETF) . Those interested can 
find the 3 GPP specification 24.229 describing the IMS 

90 network' s basic operation from an SIP perspective titled "IP 
Multimedia Call Control Protocol based on SIP and SDP" at 
httpj //www.3gpp nrH/f t p/SpecB/Latec,1-dr«€t8/24229>2ai. 8 lp. SIP 
is a request/response style protocol/ in the sense that for 
every message sent from a source, there is an associated 

25 response from the destination confirming receipt of the sent 
message. (The acknowledgement ACK message is a special case to 
which no response is sent) 

For example, in a 3G network, when a user first switches on 
30 his mobile terminal, he must register his user ID or address 
' with the network before allowing the terminal to fully 
connect. This is done by sending an SIP 'REGISTER' message 
from the terminal to the IMS, which includes details of the 
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users address. The IMS receives and processes this information 
using a serving call state control function (S-CSCF) , which in 
this context is referred to as the •registrar* * . The REGISTER 
message is only used to provide mapping between a user's alias 

5 and contact address e.g. mapping alias 

sip: mikko.lonnfors@sonera.com to a terminal's IP address. The 
IMS acknowledges the registration by sending a suitable 
acknowledge message (e.g. 200 OK message) in accordance with 
SIP. Subsequent registrations also take place (re- 1 REGISTER ' ) 

10 whenever the preceding registration has expired or is 
expiring, or when there is a change in the status of the user. 
When a user wishes to set up a session with another user, such 
as a voice call or messaging session (there is another way of 
sending messages i.e. with a SIP MESSAGE and in this case 

15 session establishment is not required) , the session 
negotiation will also be performed under SIP. 

Application servers (AS) may supply services via the IMS such 
as instant messaging, presence, local traffic reports, and 
20 conferencing facilities. An AS may reside within the. IMS 
network, or outside of it. Typically the AS is external when 
the service supported is provided by a third party- 
One specific example of status information is presence 
25 information. Users or application servers subscribing to a 
presence service can determine the ability and availability of 
another user e.g. to accept a call (depending on the equipment 
and service provider) among other presence 

features/attributes. However, in systems supporting SIP, 
30 presence can assume a variety of indicators such as 4 in the 
office and available for all calls', 'at home and available 
for private calls only', and 'busy in call' (or at least 
appear that way) . Thus presence information allows a user to 
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• «->. availability of another user before attempting 
ascertain the availability o ^ide more than 

to make a call. The presence service can provide 

ava ilable/not available. It can 
just information such as -«>^» ^ describe 
contain visual, animated or sound agents and 
various issues for e*a*le related to a game session. 

is being standardised in OMR a 
This presence service which is Being 

.openUile alliance Cwww.ope^ileaUiance ^ - ^ 
X- - gaining »*re and *ore attentat ^ ^ 
the number of presence aware applioatio 

£ uture. *s the nu^r of T^" From tha 

ureases the a^unt of prese^e i -tio . 
receiving terminal perspective in=re- 

— * = halle " 9e " :: h :Lence tfoltion are relevant to 
; i.e. which parts of the presence ^ ^ 

which application (s) . K terminal may 

applications. For e*a^le. the terminal can run 

pbone boo, application and a ga.es application. 

r IETF and 3GPP models, a tuple structure is 
,0 in the current IETF and 3G ^ ^ 

- — C ° n Tit a c It To u" describe the purpose 

„, different ^J^lS^*— 
25 name but are intended to be For ^le 

™ i-hP sending/receiving application 
depending on the sencu.ua/ , (one for games 

the usance infection can contain « t*- ^ ^ 

- - «" * r^TS. rU P-ne boo. 
t ^es may concarn^ status ^ 

30 have been designed to unoe ^signed to 

di screet, not available whereas the W lost . „ can 
ccderstand status values, shooing dea^ pa s^ ^ ^ ^ 

be seen from this example, the status 
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delivered to the correct application if they are to have the 
correct meaning. This is a problem when a terminal has two or 
more applications. This is also a problem even if the 
receiving terminal has only one application and sending 
5 terminal or presentity has multiple ones. If the data as 
provided in the example is delivered to the terminal having 
only e.g. DPB, the receiving terminal needs to be able to 
determine which tuple was intended for the DPB application. k * 

10 Currently, there is no mechanism to pass- the information to 
the correct applications other than for each application to 
check each tuple and see if the status values have any meaning 
for the application. In other words a trial and error approach 
is adopted. However, this creates uncertainty as to 

15 correctness of the information. This is because in some cases 
even if the value may be the same for an attribute, it may be 
. interpreted incorrectly by the wrong application. An example 
of this is as follows: a sending terminal has a DPB and a IM 
(instant messaging) application. It sets status values: DPB « 

20 Closed, IM » Open. In this example both applications would 
use only status values open and closed. Now if the receiving 
terminal only has an IM application and it receives both the 
DPB and IM statuses. If the receiving terminal tries the first 
status -value of DPB it understands it and presents that to the 

25 user via the IM application saying that IM application in the 
presentity' s terminal was closed even though it was open. 

It has been proposed that where a user wants to obtain 
presence information about one other user that the user is 
30 able to include filters to reduce the data from the presence 
server, that is the presence information. These filters are 
able to reduce the data from the presence server to include 
only parts that are of interest for the user. 
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The approach where both the tuple identities are used as a 
filtering criteria by watchers (users requesting presence 
information) and also the authorization is based on tuple 
identities has many disadvantages. If for example a user bexng 
watched has 4 tuples (Tl, T2, T3 and T4) and one watcher is 
only interested in tuples T2 and T3, the watcher sets filters 
to allow only tuples T2 and T3 to be notified to him. the 
watched user may then decide for some reason to start- showing 
different values, to the particular watcher concerning all 
tuples. Therefore the watched user creates new tuples T5, T6, 
T7 and T8 and creates a new access list, which allows the _ 
watcher to see tuples T5-T8, but not the tuples T1-T4. But 
the watcher has set the filtering based on the tuple identity, 
which means that no tuples are provided to him. This is 
disadvantageous . 

Another disadvantage of using the tuple identities in 
filtering is that normally the presentity does not want 
watchers to know that a particular watcher is not allowed to 
get as detailed information as another watcher, or that the 
information given to different watcher groups is slightly or 
totally different from the information given to other 
watchers. 

It is disadvantageous if the filtering settings change every 
time a watcher's authorization information is changed because 
of different detail level of information is provided to the 
watcher. This would be the case if the filtering is based on 
) the unique tuple identities. 
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Embodiments of the present invention aim to overcome one or 
several of the above problems. 

According to one aspect of the present invention, there is 
5 provided a communication system comprising a lest one user 
with which presence information is associated, said presence 
information comprising a plurality of parts, at least one of 
said parts comprising information identifying the application 
for which said at least one part is intended, 

10 

According" to a second aspect of the present invention, there 
is provided a communication method comprising the steps of 
providing presence information for an associated user, said 
presence information comprising a plurality of parts, at least 

15 one of said parts comprising information identifying an 
application for which said at least one part is intended; and 
at least one entity obtaining at least one of said parts, -said 
at least one entity having at least one entity application, 
the at least one entity obtaining the parts comprising 

20 information identifying said at least one entity application. 

According to a third aspect of the present invention, there is 
provided a user in a communications system, said user having 
associated presence information, said presence information 
25 comprising a plurality of parts, said user being arranged to 
provide at least one of said parts with information 
identifying an application for which -said at least one part is 
intended. 

30 According to a fourth aspect in the present invention, there 
is provided an entity in a communications system, said entity 
comprising at least one application obtaining means for 
obtaining at least one part of presence information associated 
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with an user, the at least one part comprising information 
identifying an application, the obtaining means being arranged 
to obtain the at least part comprising information identifying 
said at least one application. 

The quite static filtering settings possible with embodiments 
of the invention are useful especially when the filters are 
stored in a certain server (e.g. in the presence list caseHor 
the like beforehand. 

Embodiments of the invention may permit the hiding of the fact 
from watchers that there is a different level of information 
(or totally different information) to available to different 
watchers . 



15 



Embodiments of the invention may allow changes an 
authorization without affecting e.g. filtering settings or 
some other functionality which can be separated from the 
authorisation by giving more semantics to presence information 
20 elements 

Embodiments of the invention may give the " watcher the 
possibility to request semantically understandable information 
instead of basing the request on -non- meaningful" identity 
25 information. 

Brief Description of Drawings 



30 



For a better understanding of the present invention and as to 
how the same may be carried into effect, reference will now be 
made by way of example only to the accompanying drawings, in 



which: 
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Figure 1 illustrates a communication system wherein the 
present invention can be applied; 

Figure 2 illustrates schematically an embodiment of the 
invention; 

5 Figure 3 illustrates the embodiment of Figure 2 in more 

detail ; 

Figure 4 illustrates the IMS part of the system of Figure 

1 in more detail; 

Figure 5 illustrates schematically an embodiment of the 

10 invention. 

Detailed description of embodiments 

Reference will now first be made to the Figure 1, which 
15 illustrates a typical 3 rd Generation (3G) Wireless 
telecommunications system operating under the Universal Mobile 
Telecommunications System (UMTS) . At the hub of this system is 
the IP Multimedia Subsystem (IMS) 100 network, which routes 
calls and all kinds of sessions between two or more users (or 
20 between user and a network element e.g. application server) of 
the network and provides other network functions. Examples of 
users are . mobile terminal 111, laptop 112, personal desktop 
assistant (PDA) 113, Public Switched Telephone Network (PSTN) 
telephone 131, computer terminal 123, and application server 
25 121, and application server 122. The IMS uses an IP based 
network to handle these calls, which may include both voice 
calls and multimedia calls - 

The IMS network effectively acts as a gateway in a 3G system 
30 between the users 111, 112, 113, and other networks such as a 
PSTN 130 and external IP based network 120. Signalling between 
the mobile terminal and other users of the IMS network, and 
within the IMS network, is done under the Session Initiation 
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Protocol (SIP) . All references to messages that follow are SIP 
messages unless otherwise stated, and will be shown in 
capitals. It should be appreciated that although the preferred 
embodiments of the present invention have been described in 
5 the context of SIP, other embodiments of the invention can be 
implemented in non SIP environments. 

Reference will now be made to Figures 2 and 3 which show 
schematically an embodiment of the present invention. Figure 2 

10 shows a transmitting terminal 10 and a receiving terminal 12. 
The transmitting terminal 10 is arranged to provide presence 
information to the receiving terminal 12 . A presence server 14 
is provided. The presence server 14 and the transmitting 
terminal are sometimes referred to as a presentity. The 

15 presence server 14 provides the receiving terminal 12 with the 
required presence information. The presence server 14 will 
receive the presence information from the transmitting 
terminal. It should be appreciated that the connection between 
the transmitting terminal 10 and the presence server 14 as 

20 well as the connection between the presence server 14 and the 
receiving terminal will be via network elements or entities 
not shown. 

In embodiments of the present invention, a transmitting 
25 terminal 10 (which can be any of the users as discussed above 
and can be referred to as a watched (or presentity.) user) 
shall mark presence tuples so that receiving terminal 12 
(which can be any of the users discussed above and can be 
referred to as a watcher) and possibly the presence server 14 
30 can identify different parts of the presence information and 
pass them to the correct application. In particular, in 
embodiments of the present invention, a semantically 
meaningful application identity information field is provided 
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in each tuple or at least some tuples. This field is referred 
to as the application ID field. The information may be the 
identity itself or information relating to the identity. The 
transmitting application inserts an application specific 
identifier into that application identity information fxeld 
which can be recognised at the receiving end. The receiving 
terminal passes the tuples to the applications in that 
terminal identified in the application ID field. 

This will be discussed in more detail with reference to Figure 
3 in step 1, the applications 16a, 16b and 16c residing xn 
the transmitting terminal register their application 
identities with a presence engine 18 in the terminal. Afrer 
this step applications can start publishing information, that 
is sending information to the presence server (and from there 
to the receiving terminal if the watcher has made a presence 
subscription). In the example shown in Figure 3, the terminal 
ig shown as having three applications. This is by way of 
example only and a terminal or other user can have more or 
20 less than three applications. 

in step 2, each application 16 publishes presence information 
in form that contains one or more tuples and the presence 
engine attaches the application ID to each tuple. After that 

■\ a forwards the information to the 
the presence engine 18 forwards tne 

Qf >™>r 14 In alternative embodiments the 

presence server x<t. 

application can do the attachment of the application ID. 



15 



25 



30 



in step 3, the presence engine 20 of the receiving terminal 12 
gets a NOTIFY message from the presence server 14 of new 
presence information. According to the application ID (carried 
in each tuple) the tuples are routed to the corresponding 
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applications 22 of the receiving terminal by. the presence 
engine. Alternatively, each application can receive all of the. 
tuples but will ignore any tuple which has the wrong 
application identity. 

Thus every application would have it own application ID. For 
example gamel, game2, SMS, IM-1, 1K-2, e-MA.IL. If two 
terminals (1 and 2) have the same application, e.g. IM-1, the 
application ID is the same for that application. However, if 
0 terminal 3 has an application identified by IM-2 (made for 
example by another vendor) the application will have a 
different application ID than IM-1 application in terminals 1 
and 2. in such cases the provided attributes may be used by 
the different application but care should be taken because it 
.5 might be possible that the attributes or their values are not 
interpreted correctly. An example of this is where there are 
two different clients for IM. The basic functionality may be 
the same and thus the status attribute would be valid no 
matter which application interprets that but the remaining 
20 attributes may or may not be relevant at all. 

As the tuples contain the application identification, it is 
possible to provide efficient (application specific) filtering 
capabilities and also to find the right application for which 
25 the tuples are intended. 

Tuples have general structure as presented in draft -impp-cpim- 
pidf-05.txt (link: http://www.ietf.org/internet-drafts/draft- 
ietf-impp-cpim-pidf-05.txt]. Applications can then extend the 
30 "include additional information" options by defining new XML 
namespaces. XML is Extensible Markup Language (World Wide Web- 
a markup language based on SGML, and designed to remove the 
limitation imposed by HTML. Allows a page to contain a 
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definition and execution plan for the elements, and well as 
their content) . 

Who or what defines the different tuples to be used with 
5 different applications can vary. This may be dependent on the 
type of the application. Some or all tuples may be defined to 
have a standard format (standard attributes may be defined in 
for example the 3 GPP standard) . Alternatively or in addition, 
it is possible for application developers to define tuples of 
10 their own. 

In general, there are no limits to the number of tuples or 
attributes within the tuples one presentity can have. 

15 The entity that will put the application ID into each tuple 
can be the presence engine or the application publishing that 
information. The uniqueness of the application ID may in some 
embodiments of the present invention require its registration. 
This may be the case with the -uniqueness of the application ID 

20 is within other applications as well as other collections of 
information which need a semantic meaning. 

The application ID may be used in multivalue support and 
filtering. For example the application id can be used for 

25 hiding different "accuracy" levels of information. In that 
case the application id is not unique To clarify, the 
application information is unique in the sense that different 
applications should not use the same application ID but the 
same application ID can be present a multiple number of times 

30 in a presence server in the context of different tuples, the 
tuple -id is unique but there is the same application id in 
e.g. two or three tuples in a presentity f s presence 
information. The application id can then be used in the 
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filtering. In other words, the watcher (receiving terminal) 
may set a filter so that he does not receive all the available 
presence information from the watched user (presentity) . This 
filter may be set so that the watcher only receives presence 
5 information for certain applications, the filter filters out 
certain presence information or a combination of the two. 

For example, the following tuples are provided to the watcher 
(if provided by the presentity to the presence server) if a 
10 filtering is selected such that all tuples relating to "user 
provided location" are to be provided: 

Presentity=ABC 

15 TUPLE 1 

tuple-id: xyz3226 
application id = "user provided location" 
user provided location = TAMPERE 

20 TUPLE 2 

tuple -id: xyb3293 

application id = "user provided location" 
user provided location = HOME 

25 TUPLE 3 

tuple- id: xya3288 

application id = "user provided location- 
user provided location = x- coord, y- coord 

Reference is made to Figure 5 in which a first presentity 30 
provides tuples 1, 2, 3, 4 and 5. Each tuple contains an 
application ID so tuples 1 and 2 have application ID n A" , 
tuples 3 and 4 have application ID *B' and tuple 5 has 
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application -C- . A watcher 32 only want tuples with 
application »A» . A filter 34 thus filters the tuples and 
provides the user 32 with tuples 1 and 2 . It should be 
appreciated that in practice the filter may be part of the 
5 presentity, part of a separate entity such as a server or part 
of the watcher 32. The application ID is thus used to filter 
the tuples. 

The tuples may be intended for different users. Thus tuples 1, 
10 3 and 5 may be intended for one watcher and tuples 2 and 5 for 
a different watcher. Thus the watcher may only be able to 
»see» tuples 1, 3 and 5. Accordingly if the watcher wants only 
the tuples for application «A» , the watcher would be provided 
with tuple 1. The filter 34 provides this additional 
15 filtering. In .some embodiments of the invention a separate 
filter is provided or a directing means is provided for 
■ ensuring that a watcher only gets the tuples intended for it. 

It is also possible that different watcher groups have 
20 different presence information available to the respective 
groups . 

Entoodiments of the present invention permit applications to 
easily . recognize from presence information what information 
25 that particular application can interpret and understand. 

It should be appreciated that in embodiments of the present 
invention, the application identity may be used by the 
presence server when it performs the filtering operation. In 
30 some embodiments of the invention, an operator specific 
application can be provided in the presence server which would 
also utilise the application IDs. The presence server could 
for example modify some attribute values inside a tuple it 
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understands and to which user has granted access rights to the 
presence server. 

Embodiments of the present invention can be used to filter. 
For example a watcher can request only part of the presence 
information which relates to one or more specific 
applications. The filtering can be done by the presently 
being watched - either by the user or the presence servers by 
the watcher or by any other enity. The filter information can 
be prestored so that whenever presence information is provided 
by a specific presently to a specific watcher, it will be 
filtered in accordance with the required applications. The 
filtering can define the applications required, the 
applications not required or by a combination of these 
15 techniques. 

As mentioned above a watcher is typically a user as discussed 
above. A -presently" can be regarded as being a user and a 
presence server associated with that user. The presence server 
stores presence information for the users which are associated 
with that presence server. It should be appreciated that in 
practice, more than one user would be associated with each 
server. The presence server may be located in an end device 
(in terminal) . 

Presence information as currently defined in 3GPP can include 
the following information: (information but is not restricted 
to these and the requirements from stage 1 (requirements 
group) working on the standards is to develop a concept that 
30 enable presence to be extended. 

Subscriber status; Network status; communication means; 
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Contact address, Subscriber provided location; Network 
provided location; text; priority. 

Presence can also include other information like mood, 
5 favourite colour and etc.. 

It should be appreciated that embodiments of the invention are 
not restricted to the attribute called application identity 
information but can be applied to any attribute providing a 
10 similar type of operational possibility. 

Embodiments of the present invention are not limited to the 
use. of tuples. Not all systems use tuples for structuring 
presence document, for example wireless village presence 
15 handles presence information at an attribute level and in such 
case the application ID is linked to each separate attribute. - 

Figure 4 shows a schematic of the IMS network 100. The IMS. 
includes various elements including several Call State Control 
20 Functions (CSCF) . A CSCF is equivalent to a SIP server in the 
IETF architecture. 

The Interrogating CSCF (I-CSCF) 201 is the basic IMS node used 
for terminating calls in the IMS network, functioning at the 

25 edge of the network . Here , it is shown communicating with the 
external nodes of a mobile terminal 101, a PDA 113, and an 
application server (AS) 121. It should be appreciated that the 
connections between the mobile terminal, the PDA and the 
application server to the I-CSCF may not be direct, but via a 

30 suitable intermediate network such as the mobile core network 
110 for the mobile terminal, and the Internet 120 for the 
application server, as shown in Figure 1. 
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The HSS 202 is a centralised user database that interfaces 
with both the I-CSCF and the S-CSCF204, storing information on 
all users of the IMS. The I-CSCF uses the HSS to perform 
functions such as authorising of new users and retrieving 
routing information on the S-CSCF for forwarding messages from 
external elements to the S-CSCF. 

The S-CSCF is the IMS node responsible for invoking services 
related to IMS users. In this example, the S-CSCF also 
performs registrar functionality for IMS users, processing 
user registrations, The presence server functionality is 
implemented as application server. 

It should be appreciated that the description of Figure 4 is 
only a schematic representation and in practice additional 
elements such as for example a proxy-CSCF (P-CSCF) something 
missing from the sentence. It should also be appreciated that 
embodiments of the invention may be used in systems other than 
those shown in Figure 4. 

A presence package may be used for subscribing to the presence 
information of any user. The semantics of the presence package 
means that any user can send a subscription message for 
presence information to the presence server, but if there is 
no such presence package defined, the presence server would 
not be able to recognise to what event the user was trying to 
subscribe to. Therefore, the presence package needs to be. 
defined at the presence server, which can then receive and 
recognise that the subscription message for the associated 
event for changes in presence information. The presence server 
creates a state linked to the presence information, and when 
any change in the presence information occurs, it will trigger 
a response or notification. 
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It should be appreciated that although embodiments of the 
present invention have been described in the context of 3G 
using SIP, other suitable systems and interface protocols 
could be used. In particular, embodiments of the present 
invention may be. used in application in accordance with IETF 
specifications. 

It should also noted herein that while the above describes 
exemplifying embodiments of the invention, there are several 
variations and modifications which may be made to the 
disclosed solution without departing from the scope of the 
present invention as defined in the appended claims. 
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